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Abstract 

One concept for future space flights is to construct building blocks for a wide variety of avionics 
systems. Once a unit has served its original purpose, it can be removed from the original vehicle 
and reused in a similar or dissimilar function, depending on the function blocks the unit contains. 
For example: Once a lunar lander has reached the moon’s surface, an engine controller for the 
Lunar Decent Module would be removed and used for a lunar rover motor control unit or for a 
Environmental Control Unit for a Lunar Habitat. 

This senior design project included the investigation of a wide range of functions of space 
vehicles and possible uses. Specifically, this includes: 

• Determining and specifying the basic functioning blocks of space vehicles. 

• Building and demonstrating a concept model. 

• Showing high reliability is maintained. 


The specific implementation of this senior design project included a large project team made up 
of Systems, Electrical, Computer, and Mechanical Engineers/Technologists. The efforts were 
made up of several sub-groups that each worked on a part of the entire project. The large size 
and complexity made this project one of the more difficult to manage and advise. Typical 
projects only have 3-4 students, but this project had 10 students from five different disciplines. 

This paper describes the difference of this large project compared to typical projects, and the 
challenges encountered. It also describes how the systems engineering approach was 
successfully implemented so that the students were able to meet nearly all of the project 
requirements. 

NASA Faculty Fellow Program 

In early 2009, NASA’s Exploration Systems Mission Directorate (ESMD) solicited involvement 
for a summer 2009 higher education opportunity for faculty. The purpose of their program was to 
prepare faculty to enable their students to complete senior design projects with the potential for 
contribution to NASA ESMD objectives. The goal of this program was to select five faculty who 
would work for several weeks at a NASA field center on a specific ESMD project and 
incorporate the ESMD project into an existing senior design course or capstone course at their 
university in the 2009/2010 academic year. The course could have all students involved in a 
single project, or allow a subset of the enrolled students to work on a project. 


During the six weeks at the NASA center, faculty fellows worked closely with NASA engineers. 
The objective of this NASA site assignment was so the faculty could gain extensive knowledge 
on the specific selected NASA project, including the requirements, interfaces and issues 
affecting the design and potential solutions. During the summer the faculty also developed 
materials for use at their university during the academic year in support of the completion of the 
senior design project using a systems engineering approach. 

Systems Engineering 1 

Systems engineering is a methodical, disciplined approach for the design, realization, technical 
management, operations, and retirement of a system. The senior design project teams were 
encouraged to review the NASA systems engineering handbook 2 in the early stages of their 
projects. They were provided with supplemental systems engineering educational materials. 
The senior design teams were required to focus on the following systems engineering facets and 
to control their projects: 


SYSTEMS ENGINEERING 


PROJECT CONTROL 


• System Design 

- Requirements Definition 
-Technical Solution Definition 

• Product Realization 

- Design Realization 
-Evaluation 

- Product Transition 

• Technical Management 
-Technical Planning 
-Technical Control 
-Technical Assessment 
-Technical Decision Analysis 



Planning 
Risk Management ^ 

• Configuration 
Management 

• Data Management 

• Assessment 



• Management Planning 

• Integrated Assessment 

• Schedule Management 

• Configuration Management 

• Resource Management 

• Documentation and Data 
Management 

• Acquisition Management 


The system engineering design concepts crucial for project success are: 

• Successfully understanding and defining the mission objectives and operational concepts are 
keys to capturing the stakeholder expectations, which will translate into quality requirements 
over the life cycle of the project. 

• Complete and thorough requirements traceability is a critical factor in successful validation 
of requirements. 

• Clear and unambiguous requirements will help avoid misunderstanding when developing the 
overall system and when making major or minor changes. 


• Document all decisions made during the development of the original design concept in the 
technical data package. This will make the original design philosophy and negotiation results 
available to assess future proposed changes and modifications against. 

• The design solution verification occurs when an acceptable design solution has been selected 
and documented in a technical data package. The design solution is verified against the 
system requirements and constraints. However, the validation of a design solution is a 
continuing recursive and iterative process during which the design solution is evaluated 
against stakeholder expectations. 

These key areas should be monitored and assessed during the design project implementation. It 
should be noted that the UNC Charlotte Senior Design Program included many of these concepts 
in their existing program 3 ' 4 ' 5 ' 6 . 

NASA Reusable Avionics Project 

The initial proposal for this activity was to develop a General Purpose Measurement Tool for use 
on the lunar surface. However, the need for hardware/software for the Johnson Space Center 
Electronics (JSC-EV) branch had changed quite a bit since the original proposal was written in 
January 2009. There were more immediate needs than the measurement tool (specific) that can 
help NASA, specifically proof-of-concept technologies (general). The general technology 
activities could help guide the development of specific devices. Therefore, this original proposal 
was changed. 

With his technical manager (Greg Hall), Dr. Conrad discussed the technical areas of interest to 
JSC-EV, including wireless sensor networks, RFID sensing, system engineering, middleware 
networking, lunar vehicle, and measurement tools projects. There is an underlying technology 
question about reusing hardware between all of the lunar assets. For example, the lunar descent 
vehicle, the lunar habitat, and the lunar electric rover will all need electronic interfaces and 
computer controller boards. Rather than have three separate sets of electronics (and the spares 
that might be needed), a good design would reuse the one-use only lunar descent vehicle's 
computer controller board so that it could be used in the habitat or rover. The new project 
investigated the feasibility of this concept. 

Dr. Conrad investigated in more detail the avionics planned and already in the Constellation 
vehicles (Orion, Altair, habitat, Lunar Electric Rover). Many documents are in the public 
domain, but many are also contractor designs and are thus not accessible. Dr. Conrad is 
continued with a "generic" design of the different avionics vehicles and approximated, as best 
possible, the hardware and software design. An additional area of investigation was Real-time 
Ethernet, or Time-triggered Ethernet. 

One concept for future space flights is to construct building blocks for a wide variety of avionics 
systems. Once a unit has served its original purpose, it can be removed from the original vehicle 
and reused in a similar or dissimilar function, depending on the function blocks the unit contains. 


For example: Once a lunar lander has reached the moon’s surface, an engine controller for the 
Lunar Decent Module would be removed and used for a lunar rover motor control unit or for a 
Environmental Control Unit for a Lunar Hab. 

This final identified project was to include the investigation of a wide range of functions of space 
vehicles and possible uses. Specifically, this included: 

• Determining and specifying the basic functioning blocks of space vehicles. 

• Building and demonstrating a concept model. 

• Showing high reliability is maintained. 


The specific implementation of this project will required a large project team made up of 
Systems, Electrical, Computer, and Mechanical Engineers/Technologists. The efforts were to be 
made up of several sub-groups that each worked on a part of the entire project. 

General support (4): Systems 

Engineering, FPGA Engineer/ 
Technologist, FPAA Engineer/ 
Technologist, Mechanical 

Engineer/ Technologist 

Project 1 (2-3): Robotic Sensing, 

Control, and Communications 

Project 2 (2-3): Lunar Habitat 

Sensing, Control, and 
Communications 

Project 3 (2-3): Space Vehicle 

Sensing, Control, and 
Communications 

FPGA = Field Programmable Gate 
Array, FPAA = Field Programmable 
Analog Array 



This was one of the most complex projects offered by the University of North Carolina at 
Charlotte for the senior design program. Students working on this project were be given the 
experience of working on a typical industry effort, with respect to size and scope. 

The project had four subprojects. The main objective was to demonstrate that the same FPGA 
and FPAA board can be moved between three different systems. Each of the Systems were to 
have some basic functionality, i.e. the Robotic Vehicle could move in its environment and avoid 
obstacles. There were to be four deliverable products from this project: 


1 . A robotic vehicle that uses the common FPGA and FPAA boards 

2. A simulated lunar habitat that uses the common FPGA and FPAA boards 

3. A simulated space vehicle that uses the common FPGA and FPAA boards 

4. A programming and test fixture for the FPGA and FPAA boards 

Results - Student Involvement 

This project was implemented in the UNC Charlotte College of Engineering Industrial Senior 
Design Course. It was offered as one of several projects that students could choose to work on 
over the course of the fall 2009 and spring 2010 semesters. 

Students were invited to apply to participate in this project before fall courses even started. The 
objective of this early advertising was to ensure enough students would select this project as their 
first choice. Apparently our advertising approach and the allure of working on a NASA project 
was VERY successful. Twenty-five students applied early for the ten project positions, 
including four for the coveted Systems Engineer position. One half of the students were 
encouraged to apply for the project on selection day (two weeks into the course). Sixteen 
applications were submitted on selection day, and ten were assigned to the project. Several 
students were turned away so that they could work on other industry projects. 

One of the first things that the team did was to organize themselves into different teams than had 
been initially formulated by the faculty advisor. This was necessary since three fewer electrical 
and computer engineering students were allocated to the project as first proposed. The final 
assigned number of students also necessitated that the "deliverables" be reduced to three - the 
simulated space vehicle was removed from the requirements. 



The student selected as the Systems Engineer has an extensive background in industry and had a 
strong interest in project management. 

Results - Project Implementation 

Students who were selected for this project completed the requirements document, built a work 
breakdown structure of the effort, planned the project activities and designed the devices and 
vehicles in the fall, as described in the UNC Charlotte Senior Design publications 3,4 ' 5 ' 6 . Students 
implemented the designs in the spring semester (which was not complete at the time of 
publication of this paper). The Faculty Advisor, Dr. Conrad, worked closely with all team 
members to ensure success. 

Due to the size of team, it was necessary for the sub-teams to have separate meetings, with an 
occasional "all-hands meeting" of the entire team when needed. The Systems Engineer and 
Team Leads also meet with the faculty advisor on a regular basis. The team leads were 
responsible for gathering all requirements and designs for their sub-project, then forwarding 
these requirements and designs to the Systems Engineer. Any technology interfaces between 
teams were directly handled by team members - they did not go through the team leads for such 
detailed efforts. 

The team had the same problems and successes that typical large industry teams encounter, 
including the well know forming-storming-norming-performing team behavior. All storming 
behavior was resolved by the end of the first semester. 

This team, using Systems Engineering approaches at a more pronounced level than other senior 
design teams, was able to outperform nearly all other teams in first semester performance. 
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Appendix - Initial Project Statement of Work (starting on next page) 


Title: Field Reprogrammable and Reusable Avionics Unit 

Sponsor: NASA Johnson Space Center, Engineering Directorate, Avionics Systems Division 
Personnel: 10-12 Comp/Electrical/Mechanical Engineers/Technology 

Expected person-hours: 2500-3000 Deadline: Spring 2010 

Project Overview and Motivation 

One concept for future space flights is to construct building blocks for a wide variety of avionics 
systems. Once a unit has served its original purpose, it can be removed from the original vehicle 
and reused in a similar or dissimilar function, depending on the function blocks the unit contains. 
For example: Once a lunar lander has reached the moon’s surface, an engine controller for the 
Lunar Decent Module would be removed and used for a lunar rover motor control unit or for a 
Environmental Control Unit for a Lunar Hab. 

This project will include the investigation of a wide range of functions of space vehicles and 
possible uses. Specifically, this includes: 

• Determining and specifying the basic functioning blocks of space vehicles. 

• Building and demonstrating a concept model. 

• Showing high reliability is maintained. 



Example of Sensor Sub-element of Engine Controller 
Avionics package, note the sensor sab-element may be 
further divided into fundamental functioning blocks 



The specific implementation of this project will require a large project team made up of Systems, 
Electrical, Computer, and Mechanical Engineers/Technologists. The efforts are made up of 
several sub-groups that each work on a part of the entire project. 

FPGA = Field Programmable Gate Array, FPAA = Field Programmable Analog Array 


General support (4): Systems 
Engineering, FPGA Engineer/ 
Technologist, FPAA Engineer/ 
Technologist, Mechanical 
Engineer/ Technologist 
Project 1 (2-3): Robotic Sensing, 
Control, and Communications 
Project 2 (2-3): Lunar Habitat 
Sensing, Control, and 
Communications 
Project 3 (2-3): Space Vehicle 
Sensing, Control, and 
Communications 



Project Benefits 

This is one of the most complex projects offered by the senior design program. Students 
working on this project will be given the experience of working on a typical industry effort, with 
respect to size and scope. The Faculty Advisor, Dr. Conrad, will work closely with all team 
members to ensure success. Students who participate in this project will also be co-authors on 
several technical papers which will be written to describe the effort and results. This effort will 
truly be a bright spot on anyone's resume. 

Students working on this project will have the opportunity to work at NASA's Johnson Space 
Center as an intern in the summer of 2010. Interested students will need to apply for the 
internship in the fall of 2009. Summer employment is not guaranteed, but working on this 
project will provide proof of a strong commitment to NASA's goals. 

Expectations of Students 

It is expected that any skills not yet learned but required for the job will be either taken as a 
course during the first semester of this project, or will be learned on the students own time. In 
any case, the student must have a "Practitioner" level of knowledge by December. 

The entire project team will meet once a week to report progress. Other one-on-one meetings 
will be needed to discuss and work on technical matters. Students are encouraged to seek 


assistance if technology poses a specific problem. Nonetheless, this is NOT a project for 
students who expect to coast during their project. You will work, but not for excessive amounts 
of time. It is expected that student effort will be consistent during the semesters and not with a 
large peak at the end of the semesters. 

Job Descriptions 

Each position below lists certain skills needed for the project. Please indicate which position 
interests you in your cover letter. Make sure you address your skills and how they map to the 
requirements below. 

Systems Engineer (1): This position requires a solid background in multiple disciplines, i.e. 
computer, software, electrical, and mechanical engineering or technology. This person will be 
responsible for ensuring that the project not only stays on track but also remains technically 
sound. As a result, this person will need to have a working understanding of all of the 
technologies in the project (of at least an "apprentice" rating). While this person will not 
necessarily be writing code, designing circuits, or drawing mechanical parts, they should 
understand the underlying technologies. This person will also have excellent leadership and 
organizational skills. This is especially suited for a mature student with previous work 
experience. 

FPGA Engineer/Technologist (1): This position requires a solid background in developing 
electronic systems using skills learned as a junior, including analog and digital circuits. This 
person must also have additional knowledge of computer architecture and hardware. Knowledge 
of VHDL/Verilog and the Xilinx tool set is required. This person will help in the selection of an 
off-the-shelf FPGA development board and will be responsible for creating the programming and 
test fixture interfaces. This person will also assist the hardware engineers in the project sub- 
teams. 

FPAA/Analog Processor Engineer/Technologist (1): This position requires a solid 
background in developing electronic systems using skills learned as a junior, including analog 
and digital circuits. This person must also have additional knowledge of analog-to-digital and 
digital-to-analog conversion hardware. Knowledge of VHDL/Verilog and the Xilinx tool set is 
required. This person will help in the selection of an off-the-shelf FPAA development board and 
will be responsible for creating the programming and test fixture interfaces. This person will 
also assist the hardware engineers in the project sub-teams. 

Mechanical Engineer/Technologist (1): This position requires a solid background of the 
design of mechanical enclosures, cabling, and air-handling equipment for the electronics 
industry. This person will create the enclosures for all three of the subprojects and will ensure 
that, mechanically, the main processor boards can be easily removed and inserted into each of 


the projects. This person will also work with the FPGA and FPAA positions to build the test 
fixture and cabling needed for the sub-projects. They will also help with the robotic vehicle and 
other sub-projects hat need mechanical assistance. 

Software Engineer (3): This position requires a solid background in embedded systems and 
software development. The person in this position is expected to know the C programming 
language and basic computer architecture. Knowledge of Linux and VHDL is helpful but not 
necessary. This person will program the microprocessors to use the hardware developed by team 
members. 

Hardware Engineer (3): This position requires a solid background in developing electronic 
systems using skills learned as a junior, including analog and digital circuits. This person must 
also have additional novice knowledge of analog-to-digital and digital-to-analog conversion and 
computer hardware. Knowledge of VHDL/Verilog and the Xilinx tool set is required. This 
person will program the FPGA and FPAA boards, with the help of the FPGA/FPAA support 
Engineer/Technologist. They will also build any other hardware needed 

Other skills, helpful but not required, are: 

• Linux and Linux tools 

• Communications hardware/software like RS-232, USB, CAN, Wi-Fi, ZigBee/802.15.4, 
Bluetooth 

• Robotics and motor control (or plan to enroll in the Introduction to Robotics course in the 
spring of 2010). 

Project Requirements 

The project has four subprojects. The main objective is to demonstrate that the same FPGA and 
FPAA board can be moved between three different systems. Each of the Systems will have 
some basic functionality, i.e. the Robotic Vehicle will move in its environment and avoid 
obstacles. There are four deliverable products from this project: 

5. A robotic vehicle that uses the common FPGA and FPAA boards 

6. A simulated lunar habitat that uses the common FPGA and FPAA boards 

7. A simulated space vehicle that uses the common FPGA and FPAA boards 

8. A programming and test fixture for the FPGA and FPAA boards 

General Requirements 

All projects will use the same FPGA and FPAA board. All systems will be based on the Linux 
Operating System. 


Robotic Vehicle Requirements 

This vehicle can be either a small electric (0.75 by 0.60 meters) vehicle or an All Terrain 
Vehicle, both of which are available from Dr. Conrad's lab for use by the team. This vehicle will 
need to be controlled by the avionics (FPGA, FPAA, and other added electronics and cabling). 
This device should also demonstrate the ability to: 

• Communicate via 802.15.4 or 802.15.4/ZigBee 

• Communicate via Ethernet (on the bench) 

• Communicate via USB (on the bench) 

• Communicate via CAN bus 

• Sense its environment with Ultrasound, compass, accelerometer, and gyroscope (Inertial 
Measurement Unit) 

• Sense its environment (temperature, humidity, light). 

• Sense the battery temperature and voltage during charging and operation. 

• Report on the vehicle's status via wireless messages every 10 seconds. 

• Perform a movement and sensing mission (i.e. move in a 100 meter by 100 meter square). 

Lunar Habitat Requirements 

This "habitat" will need to be controlled by the avionics (FPGA, FPAA, and other added 
electronics and cabling). This device should also demonstrate the ability to: 

• Communicate via 802. 1 5.4 or 802. 1 5.4/ZigBee 

• Communicate via Ethernet (on the bench) 

• Communicate via USB (on the bench) 

• Communicate via CAN bus 

• Sense its environment (temperature, humidity, light). 

• Sense the battery temperature and voltage during charging and operation. 

• Report on the habitat's status via wireless messages every 10 seconds. 

• Maintain a constant temperature in the "habitat" by controlling air flow (fan) and a heater. 

• Control LED-based lighting in the "habitat" based on times programmed by the user and 
motion. 

• Charge batteries using a solar collector. 

• Provide a touch screen-based display to show this same status and allow the user to 
change the temperature via the touch screen 


Space Vehicle Requirements 

This "vehicle" will need to be controlled by the avionics (FPGA, FPAA, and other added 
electronics and cabling). This device should also demonstrate the ability to: 

• Communicate via 802. 1 5.4 or 802. 1 5.4/ZigBee 

• Communicate via Ethernet (on the bench) 


• Communicate via USB (on the bench) 

• Communicate via CAN bus 

• Sense its environment with Ultrasound, compass, accelerometer, and gyroscope (Inertial 
Measurement Unit) 

• Sense its environment (temperature, humidity, light). 

• Sense the battery temperature and voltage during charging and operation. 

• Report on the vehicle's status via wireless messages every 10 seconds. 

• Perform a movement and sensing mission (i.e. open a valve to maintain its position above 
the moon's surface). 

Programmer/Test Fixture Requirements 

This fixture will need to program and test the avionics (FPGA, FPAA). This device should also 
demonstrate the ability to: 

• Communicate via Ethernet 

• Communicate via USB 

• Communicate via CAN bus 


Appendix B: Designs Published for the Exposition Poster Session (Two Posters) 



Lee College of 
Engineering 
Senior Design 

UNC CHARLOTTE 


m 


Avionics 


Stephen Chapman 
Stephen Pocher 
Phu Phong 
Gary Gregory 
Sean Hicks 


Jeff Rotberg 
Andrew Hamilton 
Jacob Spahr 
Curtis Austin 
Charles Pritchard 


Programmable System on a Chip 



Purpose 

Create a reconfigure ble solution capable of controlling both a lunar 
habitat and an autonomous vehicle (subordinate device) 

Requirements 

•Provide control signals to the subordinate device 
•Connect to and draw power from the subordinate device 
•Periodically poll the subordinate device's sensors and store the data 


Developer Board Provided Courtesy of: 

Cypress Semiconductor 


PSoC Capabilities and Specifications 


* Digital System i 

•24 UDBs to instantiate any digital peripheral 
•CAN support: 16 receive and 8 transmit buffers 
•Support for 12 Mbps USB 2.0 
•Four hardware timers 


System Bus 

•8051 CPU capable of clock rates up to 67 MHz 
•64 kB available program flash memory 
•8 kB available temporary user SRAM 
^External Memory Interface ^ 


Analog System 

•Four op-amps for analog signal amplification 
•Four twitched cap/continuous time blocks 
•High-definition delta-sigma ADC unit 
^Four analog comparators 



Autonomous Vehicle Functionality 


Gyroscope 
Accelerometer _ Drive Control 
Wheel rotation sensor 


Map 

100m x 100m grid 


Sensor Functionality (Common! 




Faculty Mentor: Dr. James Conrad 

University of North Carolina at Charlotte, 9201 University City’ Blvd, Charlotte, NC 28223 








Lee College of 
Engineering 
Senior Design 

IFNC CHARIX7TTE 

Lunar Habitat 

Introduction: 

The lunar habitat is designed to test the sensing and control functionality of the PSoC 
board. Variables inside the habitat are logged and controlled, allowing the user to monitor 
and adjust conditions via the touch screen. 



Avionics 


Jeff Rotberg 
Andrew Hamilton 
Jacob Spahr 
Curtis Austin 
Charles Pritchard 


Stephen Chapman 
Stephen Pocher 
Phu Phong 
Gary Gregory 
Sean Hicks 


AutoonDUious (Lunar VMtftde 


Introduction: 


The purpose of the lunar vehicle is to fully test the functionality of the PSoC board. To 
accomplish this, the robot will maneuver a 100m x 100m area while creating an 
environmental map and logging all sensor data. 


Touch Panel Display 


^ Displays habitat environmental 
data, temperature control, and 
internal lighting control 


Solar 

5 anel Charging 1 



N 

Demonstrates 

e 

the ability to 
recharge the 
FPGA unit's 
battery from 
solar power 

A 


Temperature Control 


[ Humidity Sensor 

1 I 

Accelerometer/ 


Gyroscope 


Arduino Mega 


I Serves as communications 
hub for all habitat functions 
I Utilizes XBee for wireless 
communication with PSoC 
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Wheel Motor 
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IPbaa Controls 
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each wheel 
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[ Hall Effect sensor j 
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Faculty Mentor: Dr. James Conrad 

University of North Carolina at Charlotte, 9201 University City Blvd, Charlotte, NC 28223 























Appendix C: FPGA Block Diagrams for Applications and Interface Pin Specifications 


Mode Select (Habitat/Vehicle) 


Temperature 
Humidity 
Oxygen 
Touch Screen 
Carbon Dioxide 
Pressure 
Collision 
External Light 
Battery Temp 
Battery Charge 
Current 
Accelerometer 
Gyro 



A 


Processing 


A 


Internal 

Storage 


Inputs 


Valid Inputs and Outputs Dependent upon Mode 



Outputs 




► 

Pass/Fail 


Test Results if 
Failure 

— ► 


Pin# 


Pin 

Pin Definition 

1 P2(5] 

GPIO 

2 P2[6] 

GPIO 

3 P2[7] 

GPIO 

4 P12(4] 

I2C0:SCL, SIO 

5 P12(5] 

I2C0:SDA, SIO 

6 P6(4] 

GPIO 

7 P6[5] 

GPIO 

8 P6(6] 

GPIO 

9 P6(7] 

GPIO 

10 Vssb 


11 Ind 


12 Vboost 


13 Vbat 


14 Vssd 


15 XRES 


16 P5[0] 

GPIO 

17 P5[l] 

GPIO 

18 P5[2] 

GPIO 

19 P5(3J 

GPIO 

20 P1(0] 

GPIO, TMS, SWDIO 

21 P1(1J 

GPIO, TCK, SWDCK 

22 Pl[2] 

GPIO, Configurable XRES 

23 Pl[3) 

GPIO, TDO, SWV 

24 P1(4J 

GPIO, TDI 

25 Pl[5] 

GPIO, nTRST 

26 Vddiol 


27 Pl[61 

GPIO 

28 Pl[7] 

GPIO 

29 P12[6] 

SIO 

30 P12[7] 

SIO 

31 P5[4] 

GPIO 

32 P5[5] 

GPIO 

33 P5[6] 

GPIO 

34 P5[7] 

GPIO 

35 P15[6] 

USBIO, D+, SWDIO 

36 P15(7] 

USBIO, D-, SWDCK 

37 Vddd 


38 Vssd 


39 Vccd 


40 NC 


41 NC 


42 P15[0] 

MHzXTAL: Xo, GPIO 

43 P15(l] 

MHzXTAL: Xi.GPIO 

44 P3[0] 

IDAC1, GPIO 

45 P3[l] 

IDAC3, GPIO 

46 P3(2] 

OpAmp3-/Extrefl, GPIO 

47 P3[3] 

OpAmp3+, GPIO 

48 P3[4] 

OpAmpl-, GPIO 

49 P3(5] 

OpAmp+, GPIO 

50 Vddio3 


51 P3(6] 

GPIO, OpAmplout 

52 P3[7] 

GPIO, OpAmp3out 

53 P12[0] 

SIO, I2C1: SCL 

54 P12[l] 

SIO, I2C1: SDA 

55 P15[2] 

GPIO, kHzXTAL: Xo 

56 P15(3] 

GPIO, kHzXTAL: Xi 

57 NC 


58 NC 


59 NC 


60 NC 


61 NC 


62 NC 


63 Vcca 


64 Vssa 


65 Vdda 


66 Vssd 


67 P12[2] 

SIO 

68 P12[3] 

SIO 

69 P4[0] 

GPIO 

70 P4[l] 

GPIO 

71 P0[0) 

GPIO, OpAmp2out 

72 P0[1) 

GPIO, OpAmpOout 


Pin Description 


i connection for boost pump, 
r connection to boost pump. 

Power sense connection to boost pump. 

Battery supply to boost pump. 

Ground for all digital logic and I/O pins. 

External reset pin. Active low with internal pullup 



JTAG Test Mode Select programming and debug port connection. 
Serial Wire Debug Clock programming and debug port connection 


JTAG Test Data Out programming and debug port connection 
JTAG Test Data In programming and debug port connection 

Optional JTAG Test Reset programming and debug port connection to reset the JTAG connection. 
Supply for I/O pins 


Habitat Touch Screen- RS232 RXD (Pin 2) 
Habitat Touch Screen- RS232 TXD (Pin 3) 
Habitat Touch Screen- RS232 RTS (Pin 7) 
Habitat Touch Screen- RS232 CTS (Pin 8) 


Provides D+ connection directly to a USB 2.0 bus. 

Provides D- connection directly to a USB 2.0 bus. 

Supply for all digital peripherals and digital core regulator 


Ground for Habitat Touch Screen (Pin 5) 


Output of digital core regulator and input to digital core 



4 to 33 MHz crystal oscillator pin 


External reference input to the analog system. 


Supply for I/O pins 


32.768 kHz crystal oscillator pin 


Output of analog core regulator and input to analog core 
Ground for all analog peripherals 
Supply for all analog peripherals and analog core regulator 
Ground for all digital logic and I/O pins 








73 P0[2] 

74 P0[3] 

75 VddioO 

GPIO, OpAmpO+ 

GPIO, OpAmpO-, ExtrefO 

External reference input to the analog system. 

Xbee Module- 5 Volt Power 

76 P0[4] 

GPIO, OpAmp2+ 


77 P0[5] 

GPIO, OpAmp2- 


78 P0[6] 

GPIO, IDACO 


79 P0[7] 

GPIO, IDAC2 


80 P4[2] 

GPIO 

Xbee Module- DTR Pin 

81 P4[3] 

GPIO 

Xbee Module- RST Pin 

82 P4[4] 

GPIO 

Xbee Module- CST Pin 

83 P4[5] 

GPIO 

Xbee Module- RX Pin 

84 P4[6] 

GPIO 

Xbee Module- TX Pin 

85 P4[7] 

GPIO 

Xbee Module- RTS Pin 

86 Vccd 


Output of digital core regulator and input to digital core 

87 Vssd 

Ground for Xbee Module 

88 Vddd 


Supply for all digital peripherals and digital core regulator 

89 P6[0] 

GPIO 


90 P6[l] 

GPIO 


91 P6[2] 

GPIO 


92 P6(3] 

GPIO 


93 P15[4] 

GPIO 


94 P15[5] 

GPIO 


95 P2[0] 

GPIO 


96 P2(l] 

GPIO 


97 P2[2] 

GPIO 


98 P2(3] 

GPIO 


99 P2[4] 

GPIO 


100 Vddio2 


Supply for I/O pins 



Pin 

Pin Definition 

Pin Description 

1 P2[5] 

GPIO 


2 P2[6] 

GPIO 


3 P2 [7] 

GPIO 


4 P12[4] 

I2C0:SCL, 5IO 


5 P12[5] 

I2C0:SDA, SIO 


6 P6[4] 

GPIO 


7 P6(5] 

GPIO 


8 P6(6] 

GPIO 


9 P6[7] 

GPIO 


10 Vssb 


Ground connection for boost pump. 

11 Ind 


Inductor connection to boost pump. 

12 Vboost 


Power sense connection to boost pump. 

13 Vbat 


Battery supply to boost pump. 

14 Vssd 


Ground for all digital logic and I/O pins. 

15 XRES 


External reset pin. Active low with internal pullup 

16 P5[0] 

GPIO 


17 P5[ll 

GPIO 


18 P5[2] 

GPIO 


19 P5(3] 

GPIO 


20 P1(0] 

GPIO, TMS, SWDIO 

JTAG Test Mode Select programming and debug port connection. 

21 Pl[ll 

GPIO, TCK, SWDCK 

Serial Wire Debug Clock programming and debug port connection 

22 P 1 [2] 

GPIO, Configurable XRES 


23 Pl[3] 

GPIO, TOO, SWV 

JTAG Test Data Out programming and debug port connection 

24 PI [4] 

GPIO, TDI 

JTAG Test Data In programming and debug port connection 

25 Pl[5] 

GPIO, nTRST 

Optional JTAG Test Reset programming and debug port connection to reset the JTAG connection. 

26 Vddiol 


Supply for I/O pins 

27 Pl[6] 

GPIO 


28 Pl[7] 

GPIO 


29 P12[6] 

SIO 


30 P12(7] 

SIO 


31 P5[4] 

GPIO 


32 P5[5] 

GPIO 


33 P5[6] 

GPIO 


34 P5 [7] 

GPIO 


35 P15[6] 

USBIO, D+, SWDIO 

Provides D+ connection directly to a USB 2.0 bus. 

36 P15[7] 

USBIO, D-, SWDCK 

Provides D- connection directly to a USB 2.0 bus. 

37 Vddd 


Supply for all digital peripherals and digital core regulator 

38 Vssd 


Ground for all digital logic and I/O pins 

39 Vccd 

40 NC 

41 NC 


Output of digital core regulator and input to digital core 

42 P15[0] 

MHz XTAL: Xo, GPIO 


43 P15[l] 

MHz XTAL: Xi. GPIO 

4 to 33 MHz crystal oscillator pin 

44 P3[0] 

IDAC1, GPIO 


45 P3[ll 

IDAC3, GPIO 


46 P3[2] 

OpAmp3-/Extrefl, GPIO 

External reference input to the analog system. 

47 P3[3] 

OpAmp3+, GPIO 


48 P3[4] 

OpAmpl , GPIO 


49 P3[5) 

OpAmp+, GPIO 


50 Vddio3 


Supply for I/O pins 

51 P3|6] 

GPIO, OpAmplout 


52 P3[7] 

GPIO, OpAmp3out 


53 P12(0] 

SIO, I2C1SCL 


54 P12[l] 

SIO, I2C1SDA 


55 P15[2] 

GPIO, kHz XTAL: Xo 


56 P15[3] 

57 NC 

58 NC 

59 NC 

60 NC 

61 NC 

62 NC 

GPIO, kHz XTAL: Xi 

32.768 kHz crystal oscillator pin 

63 Vcca 


Output of analog core regulator and input to analog core 

64 Vssa 


Ground for all analog peripherals 

65 Vdda 


Supply for all analog peripherals and analog core regulator 

66 Vssd 


Ground for all digital logic and I/O pins. 

67 P12[2] 

SIO 


68 P12[3] 

SIO 


69 P4[0] 

GPIO 


70 P4[l| 

GPIO 


71 P0[0] 

GPIO, OpAmp2out 


72 P0[1] 

GPIO. OpAmpOout 


73 P0(21 

GPIO, OpAmpO+ 


74 P0[3] 

GPIO, OpAmpO-, ExtrefO 

External reference input to the analog system. 

75 VddioO 


Supply for I/O pins 

76 P0[4] 

GPIO, OpAmp2+ 


77 P0[5] 

GPIO, OpAmp2 


78 P0[6] 

GPIO, IDACO 


79 P0[7] 

GPIO, IDAC2 


80 P4[2] 

GPIO 



Vehicle Pinout 

Anlg. Photo output 
Anlg. Temp output 
Digi. wheel angle output 


Anlg. out motor left 
Anlg. Out motor right 
Anlg. Humidity 
Anlg. Range output 


Anlg. Accel out X 
Anlg. Accel out Y 
Anlg. Accel out Z 
Anlg. Gyro out X 


Anlg. Gyro out Y 


Analog Ground to Board 


81 P4[3] 

GPIO 


82 P4[4] 

GPIO 


83 P4[5] 

GPIO 


84 P4[6] 

GPIO 


85 P4[7] 

GPIO 


86 Vccd 


Output of digital core regulator and input to digital core 

87 Vssd 


Ground for all digital logic and I/O pins 

88 Vddd 


Supply for all digital peripherals and digital core regulator 

89 P6[0] 

GPIO 


90 P6[l] 

GPIO 


91 P6[2] 

GPIO 


92 P6[3] 

GPIO 


93 P15[4] 

GPIO 


94 P15[5] 

GPIO 


95 P2[0] 

GPIO 


96 P2[l] 

GPIO 


97 P2[2] 

GPIO 


98 P2[3] 

GPIO 


99 P2 [4] 

GPIO 


100 Vddio2 


Supply for I/O pins 


